1. Field of the Invention
This invention concerns update management for encoded data stored in memory. The invention applies especially to the management of security data stored in a memory of a token. The example chosen to illustrate the invention is that of the smartcard.
The invention applies especially to portable devices including a WIM (WAP Identity Module) application. This WIM application generally included in a smartcard performs, when requested by a data processing device such as a cellular telephone, operations using public keys such as electronic signatures or data encryption, etc. In this WIM application, the data is stored in memory in compliance with standard PKCS#15 (P K C S: Public-Key Cryptography Standards) defined and published by the RSA incorporation laboratories for the implementation of Public Key Cryptography. As a reminder, note that Public Key Cryptography uses a pair of keys, a public key which can be disclosed to everyone and a private key which must be kept in a safe place and never disclosed. This standard uses an object-oriented data structure, i.e. a hierarchic structure of object classes sorted by category.
Note that the RSA laboratory defines a set of standards PKCS #n (n is the identifier of the standard; RSA uses an integer to identify the various PKCS standards) designed to ensure data interoperability in heterogeneous computer systems. These various standards (PKCS#1, . . . , PKCS#15) define the data types and the algorithms used in public key cryptography. In particular, the standard PKCS#15 concerns the cryptology information stored on tokens capable of storing permanent data.
Refer to the RSA documentation describing these various standards. This document is available at the following web site: http://www.rsasecurity.com.
2. Description of the Related Art
Generally, cryptography uses a private key accessed only by a user and a public key which can be published or distributed upon request for use by those people wanting to communicate with the user. A person wanting to communicate with the user will first obtain a certificate which can be obtained from a certification authority, bearing the user's public key.
Data concerning the keys and certificates is represented by a tree structure in directories and files. Two file types are generally found in this structure:
the DF type files containing file control information (and pointers to EF files or other files),
and the EF (elementary files) type files.
In this application, we will not detail the access conditions defined at each level of the card file structure and for function groups acting on the files.
More precisely, format PKCS#15 defines four object classes attached to the root. These classes are:                the Key class,        the certificate class,        the authentication class,        and the data class.        
These classes themselves include subclasses. For example, the “Key” class includes three classes called:                private key class        secret key class        public key class        
Each object belonging to a class includes attributes. A tree therefore generally includes several objects distributed throughout the tree.
These objects and directories are represented according to the standard ASN.1 (ASN.1 Abstract Syntax Notation) ISO/IEC 8824 published by ANSI (American National Standards Institute). This standard specifies the syntax to be used to describe complex data objects.
These objects are then encoded according to Distinguished Encoding Rules (DER) defined in the same standard ASN.1. These encoding rules define the encoding of objects as byte sequences. There is no need to describe this standard ASN.1 any further since it is not the subject of the invention.
Once encoding has been carried out, an application external to the card, for example a card reader, can read the encoded data stored on the card from a directory PKCS#15 (the root) and find from the tree structure described above how to use the keys, the certificates and applications stored on the card.
Encoding is generally carried out during the card personalisation. After personalisation, some tree attributes may have to be updated. This updating is extremely complicated. Updating from a reader consists, in fact, of two main steps:                Firstly, all encoded data must be decoded,        Secondly, once updating has bee carried out, this data must be encoded again.        
These two steps must be repeated whenever at least one attribute of an object has to be updated.